Virtual computing allows multiple virtual machines, each having their own operating system, to run on a host computer. The host computer has a virtualizer program that allows the host computer to execute the instructions of a virtual machine program, which may have a different CPU model than the host computer. The host computer virtualizer program can also virtualize the hardware resources of the host machine for virtual machine use. The virtual machine that is requesting hardware resources such as CPU, memory, I/O and disk space is called a guest with respect to the host computer.
In a virtual machine, the guest computer system only exists in the host computer system as a pure software representation of the operation of one specific hardware architecture. The terms virtualizer, emulator, virtual machine, and processor emulation are sometimes used interchangeably to denote the ability to mimic or emulate the hardware architecture of an entire computer system using one or several approaches known and appreciated by those of skill in the art. A virtualizer program executing on the operating system software and hardware architecture of the host computer mimics the operation of the entire guest computer system.
The virtualizer program acts as the interchange between the hardware architecture of the host machine and the instructions transmitted by the software (e.g., operating systems, applications, etc.) running within the emulated guest virtual machine environment. In one virtual machine environment embodiment, the emulated environment may include a virtual machine monitor (VMM) which is a software layer that runs directly above the host hardware, perhaps running side-by-side and working in conjunction with the host operating system, and which can virtualize all the resources of the host machine (as well as certain virtual resources) by exposing interfaces that are the same as the hardware the VMM is virtualizing. This virtualization enables the virtualizer (as well as the host computer system itself) to go unnoticed by operating system layers running above it. In a virtual machine environment, the multiple virtual machines impose performance requirements on the hardware resources of the host machine. It is desirable to keep one virtual machine separated from the other virtual machines as well as separated from the host. Separation or isolation of one virtual machine from another is useful to isolate errors and faults such that one virtual machine fault does not affect another virtual machine.
Yet, in some configurations, it is desirable to have one virtual machine access host resources available to a second virtual machine. FIG. 1 depicts a virtual computer system 100. The system 100 includes a first virtual machine 110, a second virtual machine 115, and virtualization software 120 residing in a host computer system 105. The virtualization software assists in maintaining a controlled isolation between virtual machines by, for example, separating the virtual machine addresses from the host system addresses. The first virtual machine 110 is a software program that includes virtual machine applications 125 running on an operating system 130 having a driver 150 to access a database 145. The second virtual machine 115 is a software program that includes virtual machine applications 135 running on an operating system 140 having a virtual driver 155. The host computer system 105 has host resources such as input output channels, memory, processors, and software which may be allocated to any of the virtual machines 110, 115. In the specific example of FIG. 1, the host resource is an I/O channel 165 accessing a database 145. The configuration of FIG. 1 indicates that the second virtual machine 115 can access the database 145 by using virtual driver 155 through the virtualization software 120 to communicate with driver 150 connected to I/O path 165 to database 145.
In a virtual machine environment, the guest is allocated host system resources such as memory. An application of a guest virtual machine generates a virtual address to access memory for the guest's purpose. This virtual address is translated to a physical address related to the guest. However, each virtual machine in the virtual machine environment maintains a separate notion of a physical address space. From the perspective of a virtual machine, its physical address spaces may appear to start at physical address zero or any other page-aligned physical address and may span as large a region as is supported by the virtualization software, which keeps note of memory allocations in the various virtual machines of a host system. Shadow page tables are typically used as part of virtualization software to provide each virtual machine with a separate physical address space.
A guest physical address space or GPA space refers to a virtual machine's physical address space. Accordingly, a guest physical address or GPA refers to addresses within the GPA space. The use of a guest physical address space supports the operations of insertion, removal and query for support of the guest virtual machine. A guest virtual address or GVA is a virtual address private to a specific virtual machine. Normally, guest virtual addresses (GVAs) are translated into guest physical addresses (GPAs). However GPAs cannot be used to access host physical memory. Accordingly, GPAs are translated into host or system physical addresses (SPAs). To reduce the overhead in address translation, the virtualizer program maintains shadow page tables that map GVAs to SPAs. The virtualizer also maintains internal data structures that store the GPA to SPA mapping. FIG. 2 shows an example mapping of guest physical pages to system physical pages. Note there may be multiple guest physical addresses that can map to a single guest physical address. For example, guest physical address space page frame number PFN 202 and PFN 203 map to system physical page number PFN 102.
Operation of a virtual machine and the management of the guest physical address space can present several interesting problems. For example, when a region of guest physical address space is removed, it is necessary to purge guest virtual addresses that map to regions within the removed section of guest physical address space. This purge results in the invalidation of any outstanding mappings to regions within the removed section of GPA. Thus, if a section of GPA is removed, any virtual addresses that were constructed using GPA within the region being removed will need to be invalidated. In an example architecture, there may be two locations where GVA-to-SPA mappings are maintained, hence there are two places where these GVA-to-SPA mappings must be removed. The two areas that maintain virtual-to-physical mappings are within the shadow page tables and within the hardware translation look-aside buffer (TLB). Each of these caches must be purged to maintain the correctness of the virtualization and to prevent security breaches between virtual machines. FIG. 3 shows GVA-to-SPA mappings. Note that multiple guest virtual address may map to the same system physical address page. For example, guest virtual address VA C000:1000 and VA C000:2000 map to system physical page number PFN 102. Such a mapping is evident in a shadow page table useful to speed up the conversion of a guest virtual address to system address translation.
Unfortunately, since the shadow page table data structures maintain a mapping from GVA to SPA, it is not possible to query all GVAs that map to a specific GPA by querying the shadow page table shown in FIG. 3. However, a mapping of GPAs to SPAs as shown in FIG. 2 is also maintained. One technique to determine all guest virtual addresses that were created using a specific GPA is to query the GPA to SPA (FIG. 2) map for all SPAs that map to a specific GPA and then remove all entries from the GVA to SPA (FIG. 3 shadow page table) map that map to SPAs. Unfortunately, this method can be very slow as each of the steps involves a linear search of the GPA to SPA and GVA to SPA maps respectively. As an alternative, an inverse mapping of GPA to GVA could be maintained to explicitly handle this condition. Unfortunately, the latter approach consumes large amounts of extra memory.
An added complexity occurs because physical devices in computer systems address system memory using physical addresses and not virtual addresses. Thus, purging the virtual-to-physical mappings from the shadow page table (SPT) and translation look-aside buffer (TLB) will not prevent a physical device from physically accessing the system memory if the device is set up to perform a direct memory access (DMA) operation. DMA operations may be performed in virtual machine environments where DMA controller hardware and software are present.
When removing guest physical address space, it is important to be certain that the space is not currently involved in a DMA operation. One technique to prevent removal of a guest address space page, generally 4 K bytes or more, while an outstanding DMA transaction is ongoing is to maintain a single flag per page specifying whether the page is being used for a DMA operation. Unfortunately, different physical devices may be mapped to the same physical address space and thus the same address space may be involved in two different, possibly pending, DMA operations. Thus a single flag is not enough information to know when both DMA transactions have completed. A more advanced mechanism is desirable.
One possible solution to the multiple pending DMA operation is to provide a mechanism to prevent DMA requests to specific regions of system physical memory. Generally, a table is provided that allows the operating system to control whether a specific page may be read from or written to via a non-CPU agent, such as occurs during a DMA transaction. The table has one or more flags per page of physical memory specifying whether the page may be read from or written to via a DMA operation. This table is termed a DMA exclusion vector (DEV). It is desirable to use the DMA exclusion vector mechanism and still avoid the problem of multiple DMA transactions targeted against a physical address space that should be purged or modified from GPA tables.
Thus, there is a need for a method and system to permit the purging or modification of physical address space from reference tables used in guest to host physical address while still allowing some accesses to physical addresses, such a DMA and other I/O operations between virtual machines. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.